<html>
<head><meta charset="utf-8"><title>Arguments for derive macros · t-lang · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/index.html">t-lang</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html">Arguments for derive macros</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="240775046"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240775046" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240775046">(May 30 2021 at 21:30)</a>:</h4>
<p>I've been thinking about ways to allow derive helper attributes on standard library <code>derive</code> macros without introducing backwards compatibility problems. I think allowing arguments on derive macros (e.g. <code>#[derive(Foo(some, arguments)]</code> would be a nice way to resolve this.</p>
<p>Derive macros could use this to require an explicit opt-in towards using certain derive helper attributse. For example:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="cp">#[derive(Debug(enable_skip), SomeCustomDerive)]</span><span class="w"></span>
<span class="k">struct</span> <span class="nc">Foo</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="n">first</span>: <span class="kt">u8</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="cp">#[skip]</span><span class="w"> </span><span class="n">second</span>: <span class="nc">SomeNonDebugType</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>would cause the <code>Debug</code> macro to respect the <code>#[skip]</code> derive helper, and consequently skip the <code>second</code> field in the generated <code>Debug</code> impl. If the <code>enable_skip</code> argument is <em>not</em> provided, then the <code>Debug</code> macro will ignore the <code>#[skip]</code> attribute, and generate a <code>Debug</code> implementation that uses both fields. This means that the behavior of code like this:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="cp">#[derive(Debug, SomeCustomDerive)]</span><span class="w"></span>
<span class="k">struct</span> <span class="nc">Foo</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="w">    </span><span class="n">first</span>: <span class="kt">u8</span><span class="p">,</span><span class="w"></span>
<span class="w">    </span><span class="cp">#[skip]</span><span class="w"> </span><span class="n">second</span>: <span class="nc">SomeNonDebugType</span><span class="w"></span>
<span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>will be unchanged, so upgrading to a newer version of Rust will not silently change the behavior of existing code.</p>
<p>We would implement this by allowing proc-macros of the form:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="cp">#[proc_macro_derive(MyDerive)]</span><span class="w"></span>
<span class="k">fn</span> <span class="nf">my_derive</span><span class="p">(</span><span class="n">attr</span>: <span class="nc">TokenStream</span><span class="p">,</span><span class="w"> </span><span class="n">input</span>: <span class="nc">TokenStream</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="o">..</span><span class="p">.</span><span class="w"> </span><span class="p">}</span><span class="w"></span>
</code></pre></div>
<p>analogous to how attribute proc-macros work. We would still accept the current single-argument <code>fn my_derive(input: TokenStream) { ... }</code> function definition.</p>
<p>An additional use-case for this feature would be for using a derive macro multiple times. For example, you could have <code>#[derive(From(u8, u32))] enum Foo { A, B }</code> or <code>#[derive(From(u8))] #[derive(From(u32))] enum Foo { A, B }</code>, where <code>#[derive(From)]</code> is a custom derive macro that lets you convert an enum discriminant to an instance of the enum. I don't think this use-case is valuable enough to motivate this feature by itself, but it would make some code less verbose and more readable.</p>
<p>If people are generally in favor of the idea, I'll write up a (pre) RFC with some more detailed motivating examples</p>
<div class="codehilite"><pre><span></span><code>
</code></pre></div>



<a name="240775091"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240775091" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240775091">(May 30 2021 at 21:31)</a>:</h4>
<p>RFC <a href="https://github.com/rust-lang/rfcs/pull/3107">https://github.com/rust-lang/rfcs/pull/3107</a> could use this to make <code>#[default]</code> a derive helper instead of a built-in attribute</p>



<a name="240775283"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240775283" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240775283">(May 30 2021 at 21:36)</a>:</h4>
<p>This would also allow a nicer way of feature-gating standard library derive helpers - otherwise, we'd need to either have the feature gate change the behavior of the derive macro, or give false-positive feature gates where the derive helper overlaps with a custom derive macro</p>



<a name="240784073"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784073" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784073">(May 31 2021 at 01:56)</a>:</h4>
<p>I'd personally prefer namespacing helpers, for example std::skip or std:: default::skip, I think.</p>



<a name="240784152"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784152" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Pratt <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784152">(May 31 2021 at 01:58)</a>:</h4>
<p>I've thought about this before. I think the best way for something like this is <code>#[skip(Debug)]</code> or similar (I use <code>#[ignore]</code> when playing around myself). It would trivially permit a field to be ignored for a specific derive, but not for others.</p>



<a name="240784574"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784574" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784574">(May 31 2021 at 02:08)</a>:</h4>
<p><span class="user-mention" data-user-id="116122">@simulacrum</span> The problem with namespacing is that proc-macros need to be able to textually match derive helpers</p>



<a name="240784584"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784584" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784584">(May 31 2021 at 02:09)</a>:</h4>
<p>so, either all proc-macros need to remember to check for the namespace in every place, or rustc needs to rewrite attributes before passing them to proc-macros</p>



<a name="240784638"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784638" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784638">(May 31 2021 at 02:10)</a>:</h4>
<p>Since they're our macros we should be able to check right? Or do you mean that there's a good chance non-std macros "see" the std paths by accident?</p>



<a name="240784704"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784704" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784704">(May 31 2021 at 02:12)</a>:</h4>
<p>yeah - either we selectively rewrite the attributse based on which macro we're invoking (e.g. we only rewrite <code>#[std::skip]</code> when invoking an std macro), or we deal with the problem of accidentally overlapping an existing attribute</p>



<a name="240784781"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784781" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784781">(May 31 2021 at 02:15)</a>:</h4>
<p>also, you can define a derive proc-macro named <code>Debug</code>, and import it</p>



<a name="240784784"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784784" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784784">(May 31 2021 at 02:15)</a>:</h4>
<p>which will take precedence over the one in the prelude</p>



<a name="240784848"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784848" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784848">(May 31 2021 at 02:17)</a>:</h4>
<p>which seems somewhat contrived, but I could see someone doing that to provide a more featureful version (e.g. implementing <code>#[skip]</code> themselves</p>



<a name="240784862"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784862" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784862">(May 31 2021 at 02:17)</a>:</h4>
<p>somewhat analogous to doing <code>type Result&lt;T&gt; = std::result::Result&lt;T, MyError&gt;</code>, and importing your custom <code>Result</code></p>



<a name="240784917"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784917" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784917">(May 31 2021 at 02:18)</a>:</h4>
<p>since we're dealing with the standard library, I think we should strive for stronger backwards-compatibility guarantees than "it seems unlikely that anyone is using this particular derive helper name/argument"</p>



<a name="240784936"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Arguments%20for%20derive%20macros/near/240784936" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Arguments.20for.20derive.20macros.html#240784936">(May 31 2021 at 02:19)</a>:</h4>
<p>especially considering that the consequences of breaking backwards-compatibility here might never be seen by the affected crate author (e.g. I use an overlapping derive helper attribute, and somebody else does a <code>cargo install</code> that pulls in my crate as a dependency)</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>